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HTTP-Enabled Location Delivery (HELD) 
Abstract 


This document defines a Layer 7 Location Configuration Protocol (L7 
LCP) and describes the use of HTTP and HTTP/TLS as transports for the 
L7 LCP. The L7 LCP is used for retrieving location information from 
a server within an access network. It includes options for 
retrieving location information in two forms: by value and by 
reference. The protocol is an extensible application-layer protocol 
that is independent of the session layer. 
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(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5985. 
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1. Introduction 


The location of a Device is information that is useful for a number 
of applications. The L7 Location Configuration Protocol (LCP) 
problem statement and requirements document [RFC5687] provides some 
scenarios in which a Device might rely on its access network to 
provide location information. The Location Information Server (LIS) 
service applies to access networks employing both wired technology 
(e.g., DSL, cable) and wireless technology (e.g., WiMAX) with varying 
degrees of Device mobility. This document describes a protocol that 
can be used to acquire Location Information (LI) from a LIS within an 
access network. 


This specification identifies two types of location information that 


may be retrieved from the LIS. Location may be retrieved from the 
LIS by value; that is, the Device may acquire a literal location 
object describing the location of the Device. The Device may also 


request that the LIS provide a location reference in the form of a 
Location URI or set of Location URIs, allowing the Device to 
distribute its LI by reference. Both of these methods can be 
provided concurrently from the same LIS to accommodate application 
requirements for different types of location information. 


This specification defines an extensible XML-based protocol that 
enables the retrieval of LI from a LIS by a Device. This protocol 
can be bound to any session-layer protocol, particularly those 
capable of MIME transport. This document describes the use of HTTP 
and HTTP/TLS as transports for the protocol. 


2. Conventions and Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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This document uses the terms (and their acronym forms): Access 
Provider (AP), Location Information (LI), Location Object (LO), 
Device, Target, Location Generator (LG), Location Recipient (LR), and 
Rule Maker (RM) and Rule Holder (RH) as defined in GEOPRIV 
Requirements [RFC3693]. The terms Location Information Server (LIS), 
Access Network, Access Provider (AP), and Access Network Provider are 
used in the same context as defined in the L7 LCP Problem statement 
and Requirements document [RFC5687]. The usage of the terms Civic 
Location/Address and Geodetic Location follows the usage in many of 
the referenced documents. 


In describing the protocol, the terms "attribute" and "element" are 
used according to their context in XML. The term "parameter" is used 
in a more general protocol context and can refer to either an XML 
"attribute" or "element". 


3. Overview and Scope 


This document describes an interface between a Device and a Location 
Information Server (LIS). This document assumes that the LIS is 
present within the same administrative domain as the Device (e.g., 
the access network). The LIS exists because not all Devices are 
capable of determining LI, and because, even if a Device is able to 
determine its own LI, it may be more efficient with assistance. This 
document does not specify how LI is determined. An Access Provider 
(AP) operates the LIS so that Devices (and Targets) can retrieve 
their LI. This document assumes that the Device and Access Provider 
have no prior relationship other than what is necessary for the 
Device to obtain network access. 


This document is based on the attribution of the LI to a Device and 
not specifically a person (end user) or Target, based on the premise 
that location determination technologies are generally designed to 
locate a Device and not a person. It is expected that, for most 
applications, LI for the Device can be used as an adequate substitute 
for the end user’s LI. Since revealing the location of the Device 
almost invariably reveals some information about the location of the 
user of the Device, the same level of privacy protection demanded by 
a user is required for the Device. This approach may require either 
some additional assurances about the link between Device and target, 
or an acceptance of the limitation that unless the Device requires 
active user authentication, there is no guarantee that any particular 
individual is using the Device at that instant. 


The following diagram shows the logical configuration of some of the 


functional elements identified in [RFC3693] and the LIS defined in 
[RFC5687]. It also shows where this protocol applies, with the Rule 


Barnes Standards Track [Page 4] 


RFC 5985 HELD September 2010 


Maker and Target represented by the role of the Device. Note that 
only the interfaces relevant to the Device are identified in the 


diagram. 
dr mmm mmm mmm rr m rr rr rr rr rr rr rr rr m rr m rr rr + 
| Access Network Provider | 
| | 
| $o-------------------------------------- + | 
| Location Information Server | 
| | | | 
| | | | 
| | | | 
|o aire ieee pray ater ea aes EO 
+---------- | ---------------------------------- + 
HELD 
| 
Rule Maker - - _ PSSsSsSss==s + RE EET EE + 
o - - | Device | | Location | 
<U\ == - - | Recipient 
/ \ ear APP 
Target - - EA a d EEEa + 


Figure 1: Significant Roles 


The interface between the Location Recipient (LR) and the Device 
and/or LIS is application specific, as indicated by the APP 
annotation in the diagram and it is outside the scope of the 
document. An example of an APP interface between a Device and LR can 
be found in the SIP Location Conveyance document [LOC-CONVEY]. 


4. Protocol Overview 


A Device uses the HTTP-Enabled Location Delivery (HELD) protocol to 
retrieve its location either directly in the form of a Presence 
Information Data Format Location Object (PIDF-LO) document (by value) 
or indirectly as a Location URI (by reference). The security 
necessary to ensure the accuracy, privacy, and confidentiality of the 
Device’s location is described in the Security Considerations 
(Section 9). 


As described in the L7 LCP problem statement and requirements 
document [RFC5687], the Device MUST first discover the URI for the 
LIS for sending the HELD protocol requests. The URI for the LIS 
SHOULD be obtained from an authorized and authenticated entity. The 
details for ensuring that an appropriate LIS is contacted are 
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provided in Section 9 and in particular Section 9.1. The LIS 
discovery protocol details are out of scope of this document and are 
specified in [RFC5986]. The type of URI provided by LIS discovery is 


RECOMMENDED to be an HTTPS URI. 


The LIS requires an identifier for the Device in order to determine 
the appropriate location to include in the location response message. 
In this document, the IP address of the Device, as reflected by the 
source IP address in the location request message, is used as the 
identifier. Other identifiers are possible, but are beyond the scope 
of this document. 


4.1. Device Identifiers, NAT and VPNs 


Use of the HELD protocol is subject to the viability of the 
identifier used by the LIS to determine location. This document 
describes the use of the source IP address sent from the Device as 
the identifier used by the LIS. When Network Address Translation 
(NAT), a Virtual Private Network (VPN), or other forms of address 
modification occur between the Device and the LIS, the location 
returned could be inaccurate. 


Not all cases of NATs introduce inaccuracies in the returned 
location. For example, a NAT used in a residential Local Area 
Network (LAN) is typically not a problem. The external IP address 
used on the Wide Area Network (WAN) side of the NAT is an acceptable 
identifier for all of the Devices in the residence (on the LAN side 
of the NAT), since the covered geographical area is small. 


On the other hand, if there is a VPN between the Device and the LIS 
(for example, for a teleworker), then the IP address seen by a LIS 
inside the enterprise network might not be the right address to 
identify the location of the Device. Section 4.1.2 provides 
recommendations to address this issue. 


4.1.1. Devices and VPNs 


To minimize the impact of connections or tunnels setup for security 
purposes or for traversing middleboxes, Devices that connect to 
servers such as VPN servers, SOCKS servers, and HTTP proxy servers 
should perform their HELD query on the LIS prior to establishing a 
connection to other servers. It is RECOMMENDED that discovery 
[RFC5986] and an initial query be performed before establishing any 
connections to other servers. If a Device performs the HELD query 
after establishing a connection to another server, the Device may 
receive inaccurate location information. 
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Devices that establish VPN connections for use by other Devices 
inside a LAN or other closed network could serve as a LIS, that 
implements the HELD protocol, for those other Devices. Devices 
within the closed network are not necessarily able to detect the 
presence of the VPN. In this case, a VPN Device should provide the 
address of the LIS server it provides, in response to discovery 
queries, rather than passing such queries through the VPN tunnel. 
Otherwise, the other Devices would be totally unaware that they could 
receive inaccurate location information. 


It could also be useful for a VPN Device to serve as a LIS for other 
location configuration options such as Dynamic Host Configuration 
Protocol (DHCP) [RFC3825] or Link Layer Discovery Protocol - Media 
Endpoint Discovery [LLDP-MED]. For this case, the VPN Device that 
serves as a LIS may first acquire its own location using HELD. 


4.1.2. LIS Handling of NATs and VPNs 


In the cases where the Device connects to the LIS through a VPN or a 
NAT that serves a large geographic area or multiple geographic 
locations (for example, a NAT used by an enterprise to connect their 
private network to the Internet), the LIS might not be able to return 
accurate LI. If the LIS cannot determine LI for the Device, it 
should provide an error response to the requesting Device. The LIS 
needs to be configured to recognize identifiers that represent these 
conditions. 


LIS operators have a large role in ensuring the best possible 
environment for location determination. The LIS operator needs to 
ensure that the LIS is properly configured with identifiers that 
indicate Devices on the remote side of a NAT or VPN. In order to 
serve the Devices on the remote side of a NAT or VPN, a LIS needs to 
have a presence on the side of the NAT or VPN nearest the Device. 


4.2. Location by Value 


Where a Device requires LI directly, it can request that the LIS 
create a PIDF-LO document. This approach fits well witha 
configuration whereby the Device directly makes use of the provided 
PIDF-LO document. The details on the information that may be 
included in the PIDF-LO MUST follow the subset of those rules 
relating to the construction of the "location-info" element in the 
PIDF-LO Usage Clarification, Considerations, and Recommendations 
document [RFC5491]. Further detail is included in "Protocol 
Parameters" (Section 6). 
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4.3. Location by Reference 


Requesting location directly does not always address the requirements 
of an application. A Device can request a Location URI instead of 
literal location. A Location URI is a URI [RFC3986] of any scheme, 
which a Location Recipient (LR) can use to retrieve LI. A Location 
URI provided by a LIS can be assumed to be globally addressable; that 
is, anyone in possession of the URI can access the LIS. 


However, possession of the URI does not in any way suggest that the 
LIS indiscriminately reveals the location associated with the 
Location URI. The specific requirements associated with the 
dereference of the location are specified in [RFC5808]. The location 
dereference protocol details are out of scope of this document. As 
such, many of the requirements in [RFC5808] (e.g., canceling of 
location references) are not intended to be supported by this 
specification. It is anticipated that future specifications may 
address these requirements. 


5. Protocol Description 


As discussed in Section 4, the HELD protocol provides for the 
retrieval of the Device’s location in the form of a PIDF-LO document 
and/or Location URI(s) from a LIS. Three messages are defined to 
support the location retrieval: locationRequest, locationResponse, 
and error. 


The Location Request (locationRequest) message is described in 
Section 5.1. A Location Request message from a Device indicates 
whether location should be returned in the form of a PIDF-LO document 


(with specific type(s) of location) and/or Location URI(s). In case 
of success, the LIS replies with a locationResponse message, 
including a PIDF-LO document and/or one or more Location URIs. In 


the case of an error, the LIS replies with an error message. 


The HELD protocol messages are defined as XML documents that MUST be 
encoded in UTF-8. A MIME type "application/held+xml" is registered 
in Section 11.3 to distinguish HELD messages from other XML document 
bodies. This specification follows the recommendations and 
conventions described in [RFC3023], including the naming convention 
of the type (’+xml’ suffix) and the usage of the ’charset’ parameter. 
The ’charset’ parameter MUST be included with the XML document. 


Section 6 contains a more thorough description of the protocol 
parameters, valid values, and how each should be handled. Section 7 
contains a more specific definition of the structure of these 
messages in the form of an XML Schema [W3C.REC-xmlschema-1-20041028]. 
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Section 8 describes the use of a combination of HTTP [RFC2616], TLS 
[RFC5246], and TCP [RFC0793] for transporting the HELD messages. 


5.1. Location Request 
A location request message is sent from the Device to the LIS when 
the Device requires its own LI. The type of LI that a Device 
requests is determined by the type of LI that is included in the 


"locationType" element. 


The location request is made by sending a document formed of a 


"locationRequest" element. The LIS uses the source IP address of the 
location request message as the primary source of identity for the 
requesting Device or target. It is anticipated that other Device 


identities may be provided through schema extensions. 


The LIS MUST ignore any part of a location request message that it 
does not understand, except the document element. If the document 
element of a request is not supported, the LIS MUST return an error 
with the unsupportedMessage error code. 


5.2. Location Response 


A successful response to a location request MUST contain a PIDF-LO 
and/or Location URI(s). The response SHOULD contain location 
information of the requested "locationType". The cases whereby a 
different type of location information MAY be returned are described 
in Section 6.2. 


5.3. Indicating Errors 


If the LIS is unable to provide location information based on the 
received locationRequest message, it MUST return an error message. 
The LIS may return an error message in response to requests for any 
"locationType". 


An error indication document consists of an "error" element. The 
"error" element MUST include a "code" attribute that indicates the 
type of error. A set of predefined error codes are included in 
Section 6.3. 


Error responses MAY also include a "message" attribute that can 
include additional information. This information SHOULD be for 
diagnostic purposes only and MAY be in any language. The language of 
the message SHOULD be indicated with an "xml:lang" attribute. 
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6. Protocol Parameters 


This section describes in detail the parameters that are used for 
this protocol. Table 1 lists the top-level components used within 
the protocol and where they are mandatory (m) or optional (o) for 
each of the messages. 


+---------------- +----------- 4+------------ dr rz rr rr rr rr rr 4+------------ + 
Parameter Section Location Location Error 
Request Response 
+---------------- +----------- dre rr rr rr rr rr +------------ dre rr rr rr rr rr + 
| responseTime | 6.1 | fe) | | 
| | | | | | 
| locationType | 6.2 | o) | | 
| | | | | | 
| code | 6.3 | | | m | 
| message | 6.4 | | | fe) | 
| | | | | | 
| locationUriSet | 6.5 | | fo) | 
| | | | | | 
Presence 6.6 fe) 
(PIDF-LO) 
4+---------------- dr rr rr rr rr rr 4+------------ dr rr rr rr rr rr 4+------------ + 


Table 1: Message Parameter Usage 
6.1. "“responseTime" Parameter 


The "responseTime" attribute MAY be included in a location request 
message. The "responseTime" attribute includes a time value 
indicating to the LIS how long the Device is prepared to wait for a 
response or a purpose for which the Device needs the location. 


In the case of emergency services, the purpose of obtaining the LI 
could be either for routing a call to the appropriate Public Safety 
Answering Point (PSAP) or indicating the location to which responders 
should be dispatched. The values defined for the purpose, 
"emergencyRouting" and "emergencyDispatch", will likely be governed 
by jurisdictional policies and should be configurable on the LIS. 


The time value in the "responseTime" attribute is expressed as a non- 
negative integer in units of milliseconds. The time value is 
indicative only, and the LIS is under no obligation to strictly 
adhere to the time limit implied; any enforcement of the time limit 
is left to the requesting Device. The LIS provides the most accurate 
LI that can be determined within the specified interval for the 
specific service. 
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The LIS may use the value of the time in the "responseTime" attribute 
as input when selecting the method of location determination, where 
multiple such methods exist. If the "responseTime" attribute is 
absent, then the LIS should return the most precise LI it is capable 
of determining, with the time interval being implementation 
dependent. 


6.2. "“locationType" Parameter 


The "locationType" element MAY be included in a location request 
message. It contains a list of LI types that are requested by the 
Device. The following list describes the possible values: 


any: The LIS SHOULD attempt to provide LI in all forms available to 
Tt, 


geodetic: The LIS SHOULD return a location by value in the form of a 
geodetic location for the Target. 


civic: The LIS SHOULD return a location by value in the form of a 
civic address for the Target. 


locationURI: The LIS SHOULD return a set of Location URIs for the 
Target. 


The LIS SHOULD return the requested location type or types. The 
location types the LIS returns also depend on the setting of the 
optional "exact" attribute. If the "exact" attribute is set to 
"true", then the LIS MUST return either the requested location type 
or provide an error response. The "exact" attribute does not apply 
(is ignored) for a request for a location type of "any". Further 
detail of the "exact" attribute processing is provided in the 
following Section 6.2.1. 


When there is a request for specific locationType(s) and the "exact" 
attribute is "false", the LIS MAY provide additional location types, 
or it MAY provide alternative types if the request cannot be 
satisfied for a requested location type. The "SHOULD"-strength 
requirements on this parameter for specific location types are 
included to allow for soft-failover. This enables a fixed client 
configuration that prefers a specific location type without causing 
location requests to fail when that location type is unavailable. 

For example, a notebook computer could be configured to retrieve 
civic addresses, which is usually available from typical home or work 


situations. However, when using a wireless modem, the LIS might be 
unable to provide a civic address and thus provides a geodetic 
address. 
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The LIS SHOULD return location information in a form that is suited 
for routing and responding to an emergency call in its jurisdiction, 
specifically by value. The LIS MAY alternatively or additionally 
return a Location URI. If the "locationType" element is absent, a 
value of "any" MUST be assumed as the default. A Location URI 
provided by the LIS is a reference to the most current available LI 
and is not a stable reference to a specific location. 


It should be noted that the protocol does not support a request to 
just receive one of a subset of location types. For example, in the 
case where a Device has a preference for just "geodetic" or "civic", 
it is necessary to make the request without an "exact" attribute, 
including both location types. In this case, if neither is 
available, a LIS SHOULD return a locationURI if available. 

The LIS SHOULD provide the locations in the response in the same 
order in which they were included in the "locationType" element in 
the request. Indeed, the primary advantage of including specific 
location types in a request when the "exact" attribute is set to 
"false" is to ensure that one receives the available locations ina 
specific order. For example, a locationRequest for "civic" could 
yield any of the following location types in the response: 

o civic 

o civic, geodetic 

o civic, locationURI 

o civic, geodetic, locationURI 

o civic, locationURI, geodetic 

o geodetic, locationURI (only if civic is not available) 

o locationURI, geodetic (only if civic is not available) 

o geodetic (only if civic is not available) 

o locationURI (only if civic is not available) 

For the example above, if the "exact" attribute was "true", then the 


only possible response is either a "civic" location or an error 
message. 
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Bede "exact" Attribute 


The "exact" attribute MAY be included in a location request message 
when the "locationType" element is included. When the "exact" 
attribute is set to "true", it indicates to the LIS that the contents 
of the "locationType" parameter MUST be strictly followed. The 
default value of "false" allows the LIS the option of returning 
something beyond what is specified, such as a set of Location URIs 
when only a civic location was requested. 


A value of "true" indicates that the LIS MUST provide a location of 
the requested type or types or MUST provide an error. The LIS MUST 
provide the requested types only. The LIS MUST handle an exact 
request that includes a "locationType" element set to "any" as if the 
"exact" attribute were set to "false". 


Gra "code" Parameter 


All "error" responses MUST contain a response code. All errors are 
application-level errors and MUST only be provided in successfully 
processed transport-level responses. For example, where HTTP/HTTPS 
is used as the transport, HELD error messages MUST be carried by a 
200 OK HTTP/HTTPS response. 


The value of the response code MUST be an IANA-registered value. The 
following tokens are registered by this document: 


requestError: This code indicates that the request was badly formed 
in some fashion (other than the XML content). 


xmlError: This code indicates that the XML content of the request 
was either badly formed or invalid. 


generalLisError: This code indicates that an unspecified error 
occurred at the LIS. 


locationUnknown: This code indicates that the LIS could not 
determine the location of the Device. The same request can be 
sent by the Device at a later time. Devices MUST limit any 
attempts to retry requests. 


unsupportedMessage: This code indicates that an element in the XML 
document for the request was not supported or understood by the 
LIS. This error code is used when a HELD request contains a 
document element that is not supported by the receiver. 


timeout: This code indicates that the LIS could not satisfy the 
request within the time specified in the "responseTime" parameter. 
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cannotProvideLiType: This code indicates that the LIS was unable to 
provide LI of the type or types requested. This code is used when 
the "exact" attribute on the "locationType" parameter is set to 


"true". 

notLocatable: This code indicates that the LIS is unable to locate 
the Device and that the Device MUST NOT make further attempts to 
retrieve LI from this LIS. This error code is used to indicate 


that the Device is outside the access network served by the LIS, 
for instance, the VPN and NAT scenarios discussed in 
Section 4.1.2. 


6.4. "message" Parameter 


The "error" message MAY include one or more "message" attributes to 
convey some additional, human-readable information about the result 


of the request. The message MAY be included in any language, which 
SHOULD be indicated by the "xml:lang", attribute. The default 
language is assumed to be English ("en") [RFC5646]. 

6.5. “locationUriSet" Parameter 


The "locationUriSet" element received in a "locationResponse" message 
MAY contain any number of "locationURI" elements. It is RECOMMENDED 
that the LIS allocate a Location URI for each scheme that it supports 
and that each scheme is present only once. URI schemes and their 
secure variants, such as HTTP and HTTPS, MUST be regarded as two 
separate schemes. 


If a "locationUriSet" element is received in a "locationResponse" 
message, it MUST contain an "expires" attribute, which defines the 
length of time for which the set of "locationURI" elements are valid. 


O25 els "locationURI" Parameter 


The "locationURI" element includes a single Location URI. In order 
for a URI of any particular scheme to be included in a response, 
there MUST be a specification that defines how that URI can be used 
to retrieve location information. The details of the protocol for 
dereferencing must meet the location dereference protocol 
requirements as specified in [RFC5808] and are outside the scope of 
this base HELD specification. 


Each Location URI that is allocated by the LIS is unique to the 


Device that is requesting it. At the time the Location URI is 
provided in the response, there is no binding to a specific location 


Barnes Standards Track [Page 14] 


RFC 5985 HELD September 2010 


type and the Location URI is totally independent of the specific type 
of location it might reference. The specific location type is 
determined at the time of dereference. 


A "locationURI" SHOULD NOT contain any information that could be used 
to identify the Device or Target. Thus, it is RECOMMENDED that the 
"locationURI" element contain a public address for the LIS and an 
anonymous identifier, such as a local identifier or unlinked 
pseudonym. 


When a LIS returns a "locationURI" element to a Device, the policy on 
the "locationURI" is set by the LIS alone. This specification does 
not include a mechanism for the HELD client to set access control 
policies on a "locationURI". Conversely, there is no mechanism, in 
this protocol as defined in this document, for the LIS to provide a 
Device the access control policy to be applied to a "locationURI". 
Since the Device is not aware of the access controls to be applied to 
(subsequent) requests to dereference a "locationURI", the client 
SHOULD protect a "locationURI" as if it were a Location Object -- 
i.e., the Device SHOULD send a "locationURI" over encrypted channels 
and only to entities that are authorized to have access to the 
location. 


Further guidelines to ensure the privacy and confidentiality of the 
information contained in the "locationResponse" message, including 
the "locationURI", are included in Section 9.3. 


6.5.2. "expires" Parameter 


The "expires" attribute is only included in a "locationResponse" 
message when a "locationUriSet" element is included. The "expires" 
attribute indicates the date/time at which the Location URIs provided 
by the LIS will expire. The "expires" attribute does not define the 
length of time a location received by dereferencing the Location URI 
will be valid. The "expires" attribute is RECOMMENDED not to exceed 
24 hours and SHOULD be a minimum of 30 minutes. 


All date-time values used in HELD MUST be expressed in Universal 
Coordinated Time (UTC) using the Gregorian calendar. The XML schema 
allows use of time zone identifiers to indicate offsets from the zero 
meridian, but this option MUST NOT be used with HELD. The extended 
date-time form using upper case "T" and "Z" characters defined in 
[W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 
values. 
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Location responses that contain a "locationUriSet" element MUST 
include the expiry time in the "expires" attribute. If a Device 
dereferences a Location URI after the expiry time, the dereference 
SHOULD fail. 


6.6. "Presence" Parameter (PIDF-LO) 


A single "presence" parameter MAY be included in the 
"locationResponse" message when specific locationTypes (e.g., 
"geodetic" or "civic") are requested or a "locationType" of "any" is 
requested. The LIS MUST follow the subset of the rules relating to 
the construction of the "location-info" element in the PIDF-LO Usage 
Clarification, Considerations, and Recommendations document [RFC5491] 
in generating the PIDF-LO for the presence parameter. 


The LIS MUST NOT include any means of identifying the Device in the 
PIDF-LO unless it is able to verify that the identifier is correct 
and inclusion of identity is expressly permitted by a Rule Maker. 
Therefore, PIDF parameters that contain identity are either omitted 
or contain unlinked pseudonyms [RFC3693]. A unique, unlinked 
presentity URI SHOULD be generated by the LIS for the mandatory 
presence "entity" attribute of the PIDF document. Optional 
parameters such as the "contact" and "deviceID" elements [RFC4479] 
are not used. 


Note that the presence parameter is not explicitly shown in the XML 
schema in Section 7 for a location response message, due to XML 
schema constraints, since PIDF is already defined and registered 
separately. Thus, the "##other" namespace serves as a placeholder 
for the presence parameter in the schema. 


7. XML Schema 


This section gives the XML Schema Definition 
[W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-2-20041028] of the 
"application/held+xml" format. This is presented as a formal 
definition of the "application/heldt+xml" format. Note that the XML 
Schema Definition is not intended to be used with on-the-fly 
validation of the presence XML document. Whitespaces are included in 
the schema to conform to the line length restrictions of the RFC 
format without having a negative impact on the readability of the 
document. Any conforming processor should remove leading and 
trailing white spaces. 
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<?xml version="1.0"?> 

<xs:schema 
targetNamespace="urn:ietf:params:xml:ns:geopriv:held" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 
xmlns:held="urn:ietf:params:xml:ns:geopriv:held" 
xmlns:xml="http://www.w3.org/XML/1998/namespace" 
elementFormDefault="qualified" 
attributeFormDefault="unqualified"> 


<xs:annotation> 
<xs:documentation> 
This document (RFC 5985) defines HELD messages. 
</xs:documentation> 
</xs:annotation> 


<xs:import namespace="http://www.w3.org/XML/1998/namespace"/> 


<!-- Return Location --> 
<xs:complexType name="returnLocationType"> 
<xs:complexContent> 
<xs:restriction base="xs:anyType"> 
<xs:sequence> 
<xs:element name="locationURI" type="xs:anyURI" 
maxOccurs="unbounded"/> 
</xs:sequence> 
<xs:attribute name="expires" type="xs:dateTime" 
use="required"/> 
</xs:restriction> 
</xs:complexContent> 
</xs:complexType> 


<!-- responseTime Type --> 
<xs:simpleType name="responseTimeType"> 
<xsS:union> 
<xs:simpleType> 
<xs:restriction base="xs:token"> 
<xs:enumeration value="emergencyRouting"/> 
<xs:enumeration value="emergencyDispatch"/> 
</xs:restriction> 
</xs:simpleType> 
<xs:simpleType> 
<xs:restriction base="xs:nonNegativeInteger"> 
<xs:minInclusive value="0"/> 
</xs:restriction> 
</xs:simpleType> 
</xs:union> 
</xs:simpleType> 
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<!-- Location Type --> 
<xs:simpleType name="locationTypeBase"> 
<xs:union> 
<xs:simpleType> 
<xs:restriction base="xs:token"> 
<xs:enumeration value="any"/> 
</xs:restriction> 
</xs:simpleType> 
<xs:simpleType> 
<xs:restriction base="held:locationTypeList"> 
<xs:minLength value="1"/> 
</xs:restriction> 
</xs:simpleType> 
</xs:union> 
</xs:simpleType> 


<xs:simpleType name="locationTypeList"> 
<xs:list> 
<xs:simpleType> 
<xs:restriction base="xs:token"> 
<xs:enumeration value="civic"/> 
<xs:enumeration value="geodetic"/> 
<xs:enumeration value="locationURI"/> 
</xs:restriction> 
</xs:simpleType> 
</xs:list> 
</xs:simpleType> 


<xs:complexType name="locationTypeType"> 
<xs:simpleContent> 
<xs:extension base="held: locationTypeBase"> 
<xs:attribute name="exact" type="xs:boolean" 
use="optional" default="false"/> 
</xs:extension> 
</xs:simpleContent> 
</xs:complexType> 


<!-- Message Definitions --> 
<xs:complexType name="baseRequestType"> 
<xs:complexContent> 
<xs:restriction base="xs:anyType"> 
<xs:sequence/> 
<xs:attribute name="responseTime" type="held:responseTimeT 
use="optional"/> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:restriction> 
</xs:complexContent> 
</xs:complexType> 
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<xs:complexType name="errorType"> 
<xs:complexContent> 
<xs:restriction base="xs:anyType"> 
<xs:sequence> 
<xs:element name="message" type="held:errorMsgType" 
minOccurs="0" maxOccurs="unbounded"/> 
<xS:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs="unbounded"/> 
</xs:sequence> 
<xs:attribute name="code" type="xs:token" 
use="required"/> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:restriction> 
</xs:complexContent> 
</xs:complexType> 


<xs:complexType name="errorMsgType"> 
<xs:simpleContent> 
<xs:extension base="xs:token"> 
<xs:attribute ref="xml:lang"/> 
<xs:anyAttribute namespace="##any" processContents="lax"/> 
</xs:extension> 
</xs:simpleContent> 
</xs:complexType> 


<xs:element name="error" type="held:errorType"/> 


<!-- Location Response --> 
<xs:complexType name="locationResponseType"> 
<xs:complexContent> 
<xs:restriction base="xs:anyType"> 
<xs:sequence> 
<xs:element name="locationUriSet" 
type="held:returnLocationType" 
minOccurs="0"/> 
<xS:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs="unbounded"/> 
</xs:sequence> 
</xs:restriction> 
</xs:complexContent> 
</xs:complexType> 


<xs:element name="locationResponse" 
type="held: locationResponseType"/> 


<!-- Location Request --> 


<xs:complexType name="locationRequestType"> 
<xs:complexContent> 
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<xs:extension base="held:baseRequestType"> 
<xs:sequence> 
<xs:element name="locationType" 
type="held:locationTypeType" 
minOccurs="0"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs="unbounded"/> 
</xs:sequence> 
</xs:extension> 
</xs:complexContent> 
</xs:complexType> 


<xs:element name="locationRequest" 
type="held: locationRequestType"/> 


</xs:schema> 
HTTP Binding 


This section describes the use of HTTP [RFC2616] and HTTP over TLS 
[RFC2818] as transport mechanisms for the HELD protocol, which a 
conforming LIS and Device MUST support. 


Although HELD uses HTTP as a transport, it uses a strict subset of 
HTTP features, and due to the restrictions of some features, a LIS is 
not a fully compliant HTTP server. It is intended that a LIS can 
easily be built using an HTTP server with extensibility mechanisms 
and that a HELD Device can trivially use existing HTTP libraries. 
This subset of requirements helps implementors avoid ambiguity with 
the many options that the full HTTP protocol offers. 


A Device that conforms to this specification MAY choose not to 
support HTTP authentication [RFC2617] or cookies [RFC2965]. Because 
the Device and the LIS may not necessarily have a prior relationship, 
the LIS SHOULD NOT require a Device to authenticate, either using the 
above HTTP authentication methods or TLS client authentication. 
Unless all Devices that access a LIS can be expected to be able to 
authenticate in a certain fashion, denying access to location 
information could prevent a Device from using location-dependent 
services, such as emergency calling. Extensions to this protocol 
might result in the addition of request parameters that a LIS might 
use to decide to request Device authentication. 


A HELD request is carried in the body of an HTTP POST request. The 
Device MUST include a Host header in the request. 
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The MIME type of HELD request and response bodies is 
"application/held+xml". LIS and Device MUST provide this value in 
the HTTP Content-Type and Accept header fields. If the LIS does not 
receive the appropriate Content-Type and Accept header fields, the 
LIS SHOULD fail the request, returning a 406 (not acceptable) 
response. HELD responses SHOULD include a Content-Length header. 


Devices MUST NOT use the "Expect" header or the "Range" header in 
HELD requests. The LIS MAY return 501 (not implemented) errors if 
either of these HTTP features are used. In the case that the LIS 
receives a request from the Device containing an If-* (conditional) 
header, the LIS SHOULD return a 412 (precondition failed) response. 


The POST method is the only method REQUIRED for HELD. If a LIS 
chooses to support GET or HEAD, it SHOULD consider the kind of 
application doing the GET. Since a HELD Device only uses a POST 
method, the GET or HEAD MUST be either an escaped URL (e.g., somebody 
found a URL in protocol traces or log files and fed it into their 
browser) or somebody doing testing/debugging. The LIS could provide 
information in the HELD response indicating that the URL corresponds 
to a LIS server and only responds to HELD POST requests, or the LIS 
could instead try to avoid any leak of information by returning a 
very generic HTTP error message such as 404 (not found). 


The LIS populates the HTTP headers of responses so that they are 
consistent with the contents of the message. In particular, the 
"CacheControl" header SHOULD be set to disable caching of any PIDF-LO 
document or Location URIs by HTTP intermediaries. Otherwise, there 
is the risk of stale locations and/or the unauthorized disclosure of 
the LI. This also allows the LIS to control any caching with the 
HELD "expires" parameter. The HTTP status code MUST indicate a 2xx 
series response for all HELD locationResponse and HELD error 
messages. 


The LIS MAY redirect a HELD request. A Device MUST handle redirects 
by using the Location header provided by the server in a 3xx 
response. When redirecting, the Device MUST observe the delay 
indicated by the Retry-After header. The Device MUST authenticate 
the server that returns the redirect response before following the 
redirect, if a Device requires that the server is authenticated. A 
Device SHOULD authenticate the LIS indicated in a redirect. 


The LIS SHOULD support persistent connections and request pipelining. 
If pipelining is not supported, the LIS MUST NOT allow persistent 
connections. The Device MUST support termination of a response by 
the closing of a connection. 
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Implementations of HELD that implement HTTP transport MUST implement 
transport over TLS [RFC2818]. TLS provides message integrity and 
confidentiality between the Device and LIS. The Device MUST 
implement the server authentication method described in Section 3.1 
of [RFC2818], with an exception in how wildcards are handled. The 
leftmost label MAY contain the wildcard string "*", which matches any 
single domain name label. Additional characters in this leftmost 
label are invalid (that is, "f*.example.com" is not a valid name and 
does not match any domain name). 


The Device uses the URI obtained during LIS discovery to authenticate 
the server. The details of this authentication method are provided 
in Section 3.1 of HTTPS [RFC2818]. When TLS is used, the Device 
SHOULD fail a request if server authentication fails, except in the 
event of an emergency. 


9. Security Considerations 


HELD is a location acquisition protocol whereby the client requests 
its location from a LIS. Specific requirements and security 
considerations for location acquisition protocols are provided in 
[RFC5687]. An in-depth discussion of the security considerations 
applicable to the use of Location URIs and by-reference provision of 
LI is included in [RFC5808]. 


By using the HELD protocol, the client and the LIS expose themselves 
to two types of risk: 


Accuracy: The client receives incorrect location information. 
Privacy: An unauthorized entity receives location information. 
The provision of an accurate and privacy- and confidentiality- 
protected location to the requestor depends on the success of five 


steps: 


1. The client must determine the proper LIS. 


2. The client must connect to the proper LIS. 


3. The LIS must be able to identify the Device by its identifier (IP 


address). 
4. The LIS must be able to return the desired location. 
5. HELD messages must be transmitted unmodified between the LIS and 


the client. 
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Of these, only steps 2, 3, and 5 are within the scope of this 
document. Step 1 is based on either manual configuration or on the 
LIS discovery defined in [RFC5986], in which appropriate security 
considerations are already discussed. Step 4 is dependent on the 
specific positioning capabilities of the LIS and is thus outside the 
scope of this document. 


9.1. Assuring That the Proper LIS Has Been Contacted 


This document assumes that the LIS to be contacted is identified 
either by an IP address or a domain name, as is the case for a LIS 
discovered as described in LIS Discovery [RFC5986]. When the HELD 
transaction is conducted using TLS [RFC5246], the LIS can 
authenticate its identity, either as a domain name or as an IP 
address, to the client by presenting a certificate containing that 
identifier as a subjectAltName (i.e., as an iPAddress or dNSName, 
respectively). In the case of the HTTP binding described above, this 
is exactly the authentication described by TLS [RFC2818]. If the 
client has external information as to the expected identity or 
credentials of the proper LIS (e.g., a certificate fingerprint), 
these checks MAY be omitted. Any binding of HELD MUST be capable of 
being transacted over TLS so that the client can request the above 
authentication, and a LIS implementation for a binding MUST include 
this feature. Note that in order for the presented certificate to be 
valid at the client, the client must be able to validate the 
certificate. In particular, the validation path of the certificate 
must end in one of the client’s trust anchors, even if that trust 
anchor is the LIS certificate itself. 


9.2. Protecting Responses from Modification 


In order to prevent that response from being modified en route, 
messages must be transmitted over an integrity-protected channel. 
When the transaction is being conducted over TLS (a required feature 
per Section 9.1), the channel will be integrity protected by 
appropriate ciphersuites. When TLS is not used, this protection will 
vary depending on the binding; in most cases, without protection from 
TLS, the response will not be protected from modification en route. 


9.3. Privacy and Confidentiality 


Location information returned by the LIS must be protected from 
access by unauthorized parties, whether those parties request the 
location from the LIS or intercept it en route. As in Section 9.2, 
transactions conducted over TLS with appropriate ciphersuites are 
protected from access by unauthorized parties en route. Conversely, 
in most cases, when not conducted over TLS, the response will be 
accessible while en route from the LIS to the requestor. 
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Because HELD is an LCP and identifies clients and targets by IP 
addresses, a requestor is authorized to access location for an IP 
address only if it is the holder of that IP address. The LIS MUST 
verify that the client is the target of the returned location, i.e., 
the LIS MUST NOT provide location to other entities than the target. 
Note that this is a necessary, but not sufficient, criterion for 
authorization. A LIS MAY deny requests according to any local 
policy. 


A prerequisite for meeting this requirement is that the LIS must have 
some assurance of the identity of the client. Since the target of 
the returned location is identified by an IP address, simply sending 
the response to this IP address will provide sufficient assurance in 
many cases. This is the default mechanism in HELD for assuring that 
location is given only to authorized clients; LIS implementations 
MUST support a mode of operation in which this is the only client 
authentication. 


Using IP return routability as an authenticator means that location 
information is vulnerable to exposure through IP address spoofing 
attacks. A temporary spoofing of an IP address could mean that when 
a Device requests a Location Object or Location URI, it receives 
another Device’s location because the attacker is able to receive 
packets sent to the spoofed address. In addition, in cases where a 
Device drops off the network for various reasons, the re-use of the 
Device’s IP address could result in another Device receiving the 
original Device’s location rather than its own location. These 
exposures are limited by the following: 


o Location URIs MUST have a limited lifetime, as reflected by the 
value for the "expires" element in Section 6.5.2. The lifetime of 
Location URIs necessarily depends on the nature of the access. 


o The LIS and network SHOULD be configured so that the LIS is made 
aware of Device movement within the network and addressing 
changes. If the LIS detects a change in the network that results 
in it no longer being able to determine the location of the 
Device, then all Location URIs for that Device SHOULD be 
invalidated. 


The above measures are dependent on network configuration, which 
SHOULD be considered. For instance, in a fixed Internet access, 
providers may be able to restrict the allocation of IP addresses to a 
single physical line, ensuring that spoofing is not possible; in such 
an environment, additional measures may not be necessary. 
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10. 


Examples 


The following sections provide examples of basic HTTP/HTTPS, a simple 
location request, and a location request for multiple location types, 
along with the relevant location responses. To focus on important 
portions of messages, the examples in Sections 10.2 and 10.3 do not 
show HTTP/HTTPS headers or the XML prologue. In addition, sections 
of XML not relevant to the example are replaced with comments. 


1. Examples of HITPS Messages 


The examples in this section show complete HTTP/HTTPS messages that 
include the HELD request or response document. 


This example shows the most basic request for a LO. The POST 
includes an empty "locationRequest" element. 


POST /location HTTP/1.1 

Host: lis.example.com: 49152 

Content-Type: application/held+xml; charset=utf-8 
Content-Length: 87 


<?xml version="1.0"?> 
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/> 


Since the above request does not include a "locationType" element, 
the successful response to the request may contain any type of 
location. The following shows a response containing a minimal 
PIDF-LO. 


HTTP/1.1 200 OK 

Server: Example LIS 

Date: Tue, 10 Jan 2006 03:42:29 GMT 

Expires: Tue, 10 Jan 2006 03:42:29 GMT 
Cache-control: private 

Content-Type: application/held+xml; charset=utf-8 
Content-Length: 856 


<?xml version="1.0"?> 
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> 
<presence xmlns="urn:ietf:params:xml:ns:pidf" 
entity="pres:3650n87934c@ls.example.com"> 
<tuple id="b650sf789nd"> 
<status> 
<geopriv xmlns="urn:ietf:params:xml:ns:pidf:geoprivl1l0"> 
<location-info> 
<Point xmlns="http://www.opengis.net/gml" 
srsName="urn:ogc:def:crs:EPSG::4326"> 
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<pos>-34.407 150.88001</pos> 
</Point> 
</location-info> 
<usage-rules 
xmilns:gbp="urn:ietf:params:xml:ns:pidf:geoprivl0:basicPolicy"> 
<gbp:retention-expiry>2006-01-11T03:42:28+00:00 
</gbp:retention-expiry> 
</usage-rules> 
<method>Wiremap</method> 
</geopriv> 
</status> 
<timestamp>2006-01-10T03:42:28+00:00</timestamp> 
</tuple> 
</presence> 
</locationResponse> 


The error response to the request is an error document. The 
following response shows an example error response. 


HTTP/1.1 200 OK 

Server: Example LIS 

Expires: Tue, 10 Jan 2006 03:49:20 GMT 
Cache-control: private 

Content-Type: application/held+xml; charset=utf-8 
Content-Length: 182 


<?xml version="1.0"?> 

<error xmlns="urn:ietf:params:xml:ns:geopriv:held" 
code="locationUnknown"> 
<message xml:lang="en">Unable to determine location 
</message> 

</error> 


10.2. Example of a Simple Location Request 


The location request shown below doesn’t specify any location types 
or response time. 


<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/> 


The example response to this location request contains a list of 
Location URIs. 


<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> 
<locationUriSet expires="2006-01-01T13:00:00.0Z"> 
<locationURI>https://ls.example.com: 9768/357yc6s64ceyoiuy5ax30 
</locationURI> 
<locationURI>sip:9769+357yc6s64ceyoiuy5ax30@l1ls.example.com 
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</locationURI> 
</locationUriSet> 
</locationResponse> 


An error response to this location request is shown below: 


<error xmlns="urn:ietf:params:xml:ns:geopriv:held" 
code="locationUnknown"> 
<message xml:lang="en">Location not available 
</message> 
</error> 


10.3. An Example of a Location Request for Multiple Location Types 


The following Location Request message includes a request for 
geodetic, civic, and any Location URIs. 


2010 


<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"> 


<locationType exact="true"> 

geodetic 

civic 

locationURI 
</locationType> 
</locationRequest> 


The corresponding Location Response message includes the requeste 
location information, including two Location URIs. 


<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"> 
<locationUriSet expires="2006-01-01T13:00:00.0Z"> 
<locationURI>https://ls.example.com: 9768/357yc6s64ceyoiuy5ax3 
</locationURI> 
<locationURI>sip:9769+357yc6s64ceyoiuy5ax30@ls.example.com: 
</locationURI> 
</locationUriSet> 
<presence xmlns="urn:ietf:params:xml:ns:pidf" 
entity="pres:ae3be8585902e2253ce2@10.102.23.9"> 
<tuple id="lisLocation"> 
<status> 
<geopriv xmlns="urn:ietf:params:xml:ns:pidf:geoprivl1l0"> 
<location-info> 
<gs:Circle xmlns:gs="http://www.opengis.net/pidflo/1.0" 
xmlns:gml="http://www.opengis.net/gml" 
srsName="urn:ogc:def:crs:EPSG::4326"> 
<gml:pos>-34.407242 150.882518</gml:pos> 
<gs:radius uom="urn:ogc:def:uom:EPSG: :9001">30 
</gs:radius> 
</gs:Circle> 
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<ca:civicAddress 
xmilns:ca="urn:ietf:params:xml:ns:pidf:geoprivl0:civicAddr" 
xml:lang="en-au"> 
<ca:country>AU</ca:country> 
<ca:A1>NSW</ca:Al1> 
<ca:A3>Wollongong</ca:A3> 
<ca:A4>Gwynneville</ca:A4> 
<ca:STS>Northfield Avenue</ca:STS> 
<ca:LMK>University of Wollongong</ca:LMK> 
<ca:FLR>2</ca:FLR> 
<ca:NAM>Andrew Corporation</ca:NAM> 
<ca:PC>2500</ca:PC> 
<ca:BLD>39</ca:BLD> 
<ca:SEAT>WS-183</ca:SEAT> 
<ca:POBOX>U40</ca:POBOX> 
</ca:civicAddress> 
</location-info> 
<usage-rules 
xmins:gbp="urn:ietf:params:xml:ns:pidf:geoprivl0:basicPolicy"> 
<gbp:retransmission-allowed>false 
</gbp:retransmission-—allowed> 
<gbp: retention-expiry>2007-05-25T12:35:024+10:00 
</gbp:retention-expiry> 
</usage-rules> 
<method>Wiremap</method> 
</geopriv> 
</status> 
<timestamp>2007-05-24T12:35:02+10:00</timestamp> 
</tuple> 
</presence> 
</locationResponse> 


IANA Considerations 
IANA has made the registrations detailed in the following sections. 


1. URN Sub-Namespace Registration for 
urn:ietf:params:xml:ns:geopriv:held 


This section registers a new XML namespace, 
"urn:ietf:params:xml:ns:geopriv:held", per the guidelines in 
[RFC3688]. 


URI: urn:ietf:params:xml:ns:geopriv:held 


Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 
Mary Barnes (mary.ietf.barnes@gmail.com). 
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XML: 
BEGIN 
<?xml version="1.0"?> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
"http: //www.w3.org/TR/xhtml1/DTID/xhtmll1-strict.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> 
<head> 
<title>HELD Messages</title> 
</head> 
<body> 
<hl>Namespace for HELD Messages</h1> 
<h2>urn:ietf:params:xml:ns:geopriv:held</h2> 
<p>See RFC 5985</p> 
</body> 
</html> 
END 


11.2. XML Schema Registration 


This section registers an XML schema as per the guidelines in 
[RFC3688]. 


URI: urn:ietf:params:xml:schema:geopriv:held 


Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 
Mary Barnes (mary.ietf.barnes@gmail.com). 


Schema: The XML for this schema can be found as the entirety of 
Section 7 of this document. 


11.3. MIME Media Type Registration for ’application/held+xml’ 
This section registers the "“application/held+xml" MIME type. 
To: ietf-types@iana.org 
Subject: Registration of MIME media type application/held+xml 
MIME media type name: application 
MIME subtype name: held+xml 
Required parameters: (none) 

Optional parameters: charset 


Same as the charset parameter of "application/xml" as specified in 
RFC 3023 [RFC3023], Section 3.2. 
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Encoding considerations: Same as the encoding considerations of 
"application/xml" as specified in RFC 3023 [RFC3023], Section 3.2. 


Security considerations: This content type is designed to carry 
protocol data related to the location of an entity, which could 
include information that is considered private. Appropriate 
precautions should be taken to limit disclosure of this 


information. 
Interoperability considerations: This content type provides a basis 
for a protocol. There are multiple interoperable implementations 


of this protocol. 
Published specification: RFC 5985 


Applications which use this media type: Location information 
providers and consumers. 


Additional Information: 


Magic Number(s): (none) 
File extension(s): .heldxml 
Macintosh File Type Code(s): "TEXT" 


Person & email address to contact for further information: 
Mary Barnes <mary.ietf.barnes@gmail.com> 


Intended usage: LIMITED USE 

Author/Change controller: The IETF 

Other information: This media type is a specialization of 
application/xml [RFC3023], and many of the considerations 
described there also apply to application/held+xml. 

11.4. Error Code Registry 

As defined in this document, IANA created a new registry for the HELD 

protocol including an initial registry for error codes. The error 

codes are included in HELD error messages as described in Section 6.3 

and defined in the schema in the ’codeType’ token in the XML schema 

in Section 7. 

The following is a summary of the registry: 


Related Registry: Geopriv HELD Registries, Error codes for HELD 


Defining RFC: RFC 5985 
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Registration/Assignment Procedures: Following the policies outlined 
in [RFC5226], the IANA policy for assigning new values for the 
Error codes for HELD is Standards Action: Values are assigned only 
for Standards Track RFCs approved by the IESG. 


Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), 
Mary Barnes (mary.ietf.barnes@gmail.com). 


This section registers the following eight initial error codes as 
described in Section 6.3: 


requestError: This code indicates that the request was badly formed 
in some fashion. 


xmlError: This code indicates that the XML content of the request 
was either badly formed or invalid. 


generalLisError: This code indicates that an unspecified error 
occurred at the LIS. 


locationUnknown: This code indicates that the LIS could not 
determine the location of the Device. 


unsupportedMessage: This code indicates that the request was not 
supported or understood by the LIS. This error code is used when 
a HELD request contains a document element that is not supported 
by the receiver. 


timeout: This code indicates that the LIS could not satisfy the 
request within the time specified in the "responseTime" parameter. 


cannotProvideLiType: This code indicates that the LIS was unable to 
provide LI of the type or types requested. This code is used when 
the "exact" attribute on the "locationType" parameter is set to 


"true". 

notLocatable: This code indicates that the LIS is unable to locate 
the Device and that the Device MUST NOT make further attempts to 
retrieve LI from this LIS. This error code is used to indicate 


that the Device is outside the access network served by the LIS; 
for instance, the VPN and NAT scenarios discussed in 
Section 4.1.2. 


Barnes Standards Track [Page 31] 


RFC 5985 HELD September 2010 


12. Contributors 


James Winterbottom, Martin Thomson and Barbara Stark are the authors 
of the original document, from which this WG document was derived. 
Their contact information is included below. They made additional 
contributions to the WG document, including the XML schema. 


James Winterbottom 
Andrew 

Andrew Building (39) 
University of Wollongong 
Northfields Avenue 
Wollongong, NSW 2522 

AU 


Phone: +61 2 4221 2938 
EMail: james.winterbottom@andrew.com 
URI: http://www.andrew.com/ 


Martin Thomson 

Andrew 

Andrew Building (39) 
University of Wollongong 
Northfields Avenue 
Wollongong, NSW 2522 

AU 


Phone: +61 2 4221 2915 
EMail: martin.thomson@andrew.com 
URI: http://www.andrew.com/ 


Barbara Stark 
BellSouth 

Room 7A43 

725 W Peachtree St. 
Atlanta, GA 30308 
US 


EMail: barbara.stark@att.com 
13. Acknowledgements 


The author and contributors would like to thank the participants in 
the GEOPRIV WG and the following people for their constructive input 
and feedback on this document (in alphabetical order): Nadine Abbott, 
Bernard Aboba, Eric Arolick, Richard Barnes (in particular, the 
security considerations section), Peter Blatherwick, Ben Campbell, 


Barnes Standards Track [Page 32] 


RFC 5985 


Guy Caron, 


HELD September 2010 


Eddy Corbett, Martin Dawson, Lisa Dusseault, Robins 


George, Jerome Grenier, Ted Hardie, Cullen Jennings, Neil Justusson, 


Tat Lam, Marc Linsner, Patti McCalmont, Alexey Melnikov, Roger 

Marshall, Tim Polk, Perry Prozeniuk, Carl Reed, Julian Reschke, Eric 

Rescorla, Dan Romascanu, Brian Rosen, John Schnizlein, Shida 

Schubert, Henning Schulzrinne, Ed Shrum, Doug Stuard, Hannes 

Tschofenig, and Karl Heinz Wolf. 

14. References 
14.1. Normative References 

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
Requirement Levels", BCP 14, RFC 2119, March 1997. 

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 

[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 

[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 
Mechanism", RFC 2965, October 2000. 

[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 
January 2004. 

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 
(TLS) Protocol Version 1.2", RFC 5246, August 2008. 

[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV 
Presence Information Data Format Location Object (PIDF-LO) 
Usage Clarification, Considerations, and Recommendations", 
RFC 5491, March 2009. 

[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 
Languages", BCP 47, RFC 5646, September 2009. 

[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local 


Location Information Server (LIS)", RFC 5986, 
September 2010. 


[W3C.REC-xmlschema-1-20041028] 


Barnes 


Thompson, H., Mendelsohn, N., Beech, D., and M. Maloney, 
"XML Schema Part 1: Structures Second Edition", World Wide 
Web Consortium Recommendation REC-xmlschema-1-20041028, 
October 2004, 
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. 


Standards Track [Page 33] 


RFC 5985 


HELD September 2010 


[W3C.REC-xmlschema-2-20041028] 


Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes 
Second Edition", World Wide Web Consortium 
Recommendation REC-xmlschema-2-20041028, October 2004, 
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>. 


14:32: Informative References 


[LLDP-MED ] 


TIA, "ANSI/TIA-1057 Link Layer Discovery Protocol - Media 
Endpoint Discovery". 


[LOC-CONVEY ] 


[RFCO793] 


[RFC2617] 


[RFC3023] 


[RFC3693] 


[RFC3825] 


[RFC3986] 


[RFC4479] 


[RFC5226] 


Barnes 


Polk, J., Rosen, B., and J. Peterson, "Location Conveyance 
for the Session Initiation Protocol", Work in Progress, 
July 2010. 


Postel, J., “Transmission Control Protocol", STD 7, 
RFC 793, September 1981. 


Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 
Leach, P., Luotonen, A., and L. Stewart, "HTTP 
Authentication: Basic and Digest Access Authentication", 
RFC 2617, June 1999. 


Murata, M., St. Laurent, S., and D. Kohn, "XML Media 
Types", RFC 3023, January 2001. 


Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 
J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 


Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host 
Configuration Protocol Option for Coordinate-based 
Location Configuration Information", RFC 3825, July 2004. 


Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 
Resource Identifier (URI): Generic Syntax", STD 66, 
RFC 3986, January 2005. 


Rosenberg, J., "A Data Model for Presence", RFC 4479, 
July 2006. 


Narten, T. and H. Alvestrand, "Guidelines for Writing an 


IANA Considerations Section in RFCs", BCP 26, RFC 5226, 
May 2008. 


Standards Track [Page 34] 


RFC 5985 


[RFC5687] 


[RFC5808] 


Barnes 


HELD September 2010 


Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 
Location Configuration Protocol: Problem Statement and 
Requirements", RFC 5687, March 2010. 


Marshall, R., "Requirements for a Location-by-Reference 
Mechanism", RFC 5808, May 2010. 


Standards Track [Page 35] 


RFC 5985 HELD September 2010 


Appendix A. HELD Compliance to IETF LCP Requirements 


This appendix describes HELD’s compliance to the requirements 
specified in [RFC5687]. 


A.L. L7-1: Identifier Choice 


"The L7 LCP MUST be able to carry different identifiers or MUST 
define an identifier that is mandatory to implement. Regarding the 
latter aspect, such an identifier is only appropriate if it is from 
the same realm as the one for which the location information service 
maintains identifier to location mapping." 


COMPLY 


HELD uses the IP address of the location request message as the 
primary source of identity for the requesting Device or target. This 
identity can be used with other contextual network information to 
provide a physical location for the Target for many network 
deployments. There may be network deployments where an IP address 
alone is insufficient to identify a Target in a network. However, 
any necessary identity extensions for these networks is beyond the 
scope of this document. 


A.2. L7-2: Mobility Support 


"The GEOPRIV Layer 7 Location Configuration Protocol MUST support a 
broad range of mobility from Devices that can only move between 
reboots, to Devices that can change attachment points with the impact 
that their IP address is changed, to Devices that do not change their 
IP address while roaming, to Devices that continuously move by being 
attached to the same network attachment point." 


COMPLY 


Mobility support is inherently a characteristic of the access network 
technology, and HELD is designed to be access network agnostic. 
Consequently, HELD complies with this requirement. In addition, HELD 
provides specific support for mobile environments by providing an 
optional responseTime attribute in location request messages. 
Wireless networks often have several different mechanisms at their 
disposal for position determination (e.g., assisted GPS versus 
determining the location based on the identity of the serving base 
station), each providing different degrees of accuracy and taking 
different amounts of time to yield a result. The responseTime 
parameter provides the LIS with a criterion which it can use to 
select a location determination technique. 
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A.3. L7-3: ASP and Access Network Provider Relationship 


"The design of the L7 LCP MUST NOT assume a business or trust 
relationship between the Application Service Provider (ASP) and the 
Access Network Provider. Requirements for resolving a reference to 
location information are not discussed in this document." 


COMPLY 


HELD describes a location acquisition protocol between a Device anda 
LIS. In the context of HELD, the LIS is within the Access Network. 
Thus, HELD is independent of the business or trust relationship 
between the Application Service Provider (ASP) and the Access Network 
Provider. Location acquisition using HELD is subject to the 
restrictions described in Section 9. 


A.4. L7-4: Layer 2 and Layer 3 Provider Relationship 


"The design of the GEOPRIV Layer 7 Location Configuration Protocol 
MUST assume that there is a trust and business relationship between 
the L2 and the L3 provider. The L3 provider operates the LIS and 
needs to obtain location information from the L2 provider since this 
one is closest to the end host. If the L2 and L3 provider for the 
same host are different entities, they cooperate for the purposes 
needed to determine end system locations." 


COMPLY 


HELD was specifically designed with this model in mind and readily 
allows itself to chaining requests between operators without a change 
in protocol being required. HELD is a webservices protocol which can 
be bound to transports other than HTTP, such as BEEP. Using a 
protocol such as BEEP offers the option of high request throughput 
over a dedicated connection between an L3 provider and an L2 provider 
without incurring the serial restriction imposed by HTTP. This is 
less easy to do with protocols that do not decouple themselves from 
the transport. 


A.5. L7-5: Legacy Device Considerations 


"The design of the GEOPRIV Layer 7 Location Configuration Protocol 
MUST consider legacy residential NAT Devices and Network Termination 
Equipment (NTE) in an DSL environment that cannot be upgraded to 
support additional protocols, for example to pass additional 
information through DHCP." 
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COMPLY 


HELD is an application protocol and operates on top of IP. A HELD 
request from a host behind a residential NAT will traverse the NAT 
acquiring the external address of the home router. The location 
provided to the host therefore will be the address of the home router 
in this circumstance. No changes are required to the home router in 
order to support this function, HELD was designed specifically to 
address this deployment scenario. 


A.6. L7-6: VPN Awareness 


"The design of the GEOPRIV Layer 7 Location Configuration Protocol 
MUST assume that at least one end of a VPN is aware of the VPN 
functionality. In an enterprise scenario, the enterprise side will 
provide the LIS used by the client and can thereby detect whether the 
LIS request was initiated through a VPN tunnel." 


COMPLY 


HELD does not preclude a LIS on the far end of a VPN tunnel from 
being aware that the client request is occurring over that tunnel. 
It also does not preclude a client Device from accessing a LIS 
serving the local physical network and subsequently using the 
location information with an application that is accessed over a VPN 
tunnel. 


A.7. L7-7: Network Access Authentication 


"The design of the GEOPRIV Layer 7 Location Configuration Protocol 
MUST NOT assume prior network access authentication." 


COMPLY 


HELD makes no assumptions about prior network access authentication. 
HELD strongly recommends the use of TLS with server-side certificates 
for communication between the endpoint and the LIS. There is no 
requirement for the endpoint to authenticate with the LIS. 


A.8. L7-8: Network Topology Unawareness 
"The design of the GEOPRIV Layer 7 Location Configuration Protocol 
MUST NOT assume end systems being aware of the access network 


topology. End systems are, however, able to determine their public 
IP address(es) via mechanisms such as STUN or NSIS NATFW NSLP." 
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COMPLY 

HELD makes no assumption about the network topology. HELD doesn’t 
require that the Device know its external IP address, except where 
that is required for discovery of the LIS. 


A.9. L7-9: Discovery Mechanism 


"The L7 LCP MUST define a single mandatory to implement discovery 
mechanism." 


COMPLY 
HELD uses the discovery mechanism in [RFC5986]. 

A.10. L7-10: PIDF-LO Creation 
"When a LIS creates a PIDF-LO per RFC 4119 then it MUST put the 
<geopriv> element into the <device> element of the presence document 
(see RFC 4479). This ensures that the resulting PIDF-LO document, 
which is subsequently distributed to other entities, conforms to the 
rules outlined in [now RFC 5941]." 
COMPLY 
HELD protocol overview (Section 4) describes the requirements on the 
LIS in creating the PIDF-LO and prescribes that the PIDF-LO generated 
by the LIS MUST conform to [RFC5491]. 
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